1. Field of the Invention
This invention relates to implementing a user interface for a data processing system, and more particularly to representing all elements of the interface as objects in an object database.
2. Description of the Related Art
The term system management refers to the facilities or tools used to manage the configurable domains that a user is exposed to in a data processing system environment. A domain may be those devices, users, distributed file system, subsystems, and networks in a system; where the system may extend beyond a single machine. The system management facilities for each of the configurable domains may include the means to configure the system components when components are added or deleted from a system, means to configure a data processing system within a network of other data processing systems, and/or means to diagnose failures in the system components or the system configuration, etc. Traditionally, system management is treated as an ancillary element of an operating system environment; made up of an assortment of disjoint tools which collectively offer the administrator/user the ability to manage and monitor various aspects of the system.
In order for a user to perform tasks within a data processing system, there must be an interaction between the user and the data processing system. Instead of requiring the user to enter the data required by the processing system in the language that the processing system understands, user interfaces are created so that the user can enter data into the data processing system and receive information back in a language and facility that is easy for the user to understand and manipulate. These user interfaces are quite numerous and varied.
Some dialogue managers are based on tag languages. Tag languages require a developer who is creating a screen to know a specific non-programming language. The tag language specifies the screen layout on a total screen by screen basis. Specifying the screen layout includes specifying strings that are to appear on the screen, specifying the allowed values for the fields within the screen, and specifying the actions to be taken by a user. In addition, the tag language for one complete screen also specifies the next total screen that is to appear subsequently.
One user interface, used for performing system management tasks, groups system management tools based on their function, and presents to the user a hierarchy of menus, solicits inputs for required parameters, and executes the functions. This interface uses a database of tables to store information about menus and options. However, since many of the same options appear in many of the same menus, the database is required to maintain all of the possible permutations between the menus and options. Excessive storage requirements within this database are necessitated since data on each option and menu are stored repetitively throughout the database. Therefore, if a change to one of the options or menus were made, the database can not be updated just once, but must be updated at all of the locations where instances of that data resides. No one table within the database is sufficient to define any single interface object or group of objects, such as a menu or options within that menu.
In addition, there is no ability to discover or develop the system information during the execution of the interface tool. Therefore all system resource attribute values presented to the user must be initialized at development time, and can not reflect the true state of the system at the time of execution of the interface tool. Therefore, the validation of user input for parameter values must be checked against these values initialized at development instead of being checked against the values that are actually valid based on the runtime configuration of the system resource. Similarly, messages displayed in this interface tool are initialized in the database tables rather than arising from the workings of the system itself.
Generally, to update or change the interface database, it must be locked until changes are complete. This means that the database can not be modified until the end of the interface tool session. Any modifications made to the database through the interface tool are not immediately reflected in the interface tool until the next session of the interface tool. In addition, only system administrators typically are allowed to modify the database.
Users generally are required to enter the hierarchy of the interface tool at a specified point. This requires that a user be presented a sequence of preliminary menus before the menu pertinent to the users task is presented.
Typically, these known interfaces are bound to one graphic representation. This decreases the interface's portability to other systems having other graphic libraries. In addition, the interface database must be rewritten or another database completely redeveloped if the menus, options, messages, etc., are to support screen presentations in multiple languages.
Also, in some interface tools, the actions to be performed in order to operate the tool are mixed together with the jobs to be performed by the functional layer in menus. For example, the functions “exit”, “go to next screen”, “go to previous screen”, are contained within the menus and not the interface tool. As a result, if an administrator adds new menus, these functions must be included. Otherwise, if they are excluded, the user has no means for escaping from the interface tool.